On Thu, 3 Nov 1994, Perry E. Metzger wrote: > I also haven't tried running the program that generates random code > and executes it lately. I believe it was called something like > "crashme" but I'm probably wrong. I recall that it used to do nicely > under older 4.1.X environments, though the latest 4.1.3s might not go > south any longer. I'll have to check... It is indeed called "crashme" - here's the README: Notes for release 1.8 of Crashme. 27-SEP-1991 GJC@MITECH.COM Many people have suggested that the output of previous versions was far too verbose, and that that was not only anoying but also effectively slowing down the program. Therefore there is a new argument available after the subprocess control argument, which is a verboseness level from 0 to 5. Using a level of 2 will print out only summary information about the runs. e.g. $ crashme +2000 666 50 00:30:00 2 Crashme: (c) Copyright 1990, 1991 George J. Carrette Version: 1.7 25-SEP-1991 Subprocess run for 1800 seconds (0 00:30:00) Test complete, total real time: 1801 seconds (0 00:30:01) exit status ... number of cases 1100 ... 2 3522652 ... 4 1036 ... 1 1084 ... 7 1108 ... 19 1 ... 432 12 ... 137 The table of exit status codes and frequencies is a new interesting aspect of the test. This test was run on a VMS system, so that we have a normal process exit 432 times, access violation 137 times, and reserved operand fault 19 times, etc. As the number of tries goes up (50 in this case) we would expect that the number of normal process exits to go down. Here is some output supplied by nik@infonode.ingr.com on one of his machines. Processor : Intergraph Clipper C300 RISC processor 16Mb memory + 4k I cache and 4K D cache Operating System: CLIX Version c.5.3.2 derived from AT&T SVR 3.1 with BSD enhancements. Crashme: (c) Copyright 1990, 1991 George J. Carrette Version: 1.7 25-SEP-1991 Subprocess run for 9000 seconds (0 02:30:00) Test complete, total real time: 9004 seconds (0 02:30:04) exit status ... number of cases 136 ... 1 24576 ... 1 14 ... 1 138 ... 11 135 ... 27 140 ... 26 132 ... 430 139 ... 18 12800 ... 567 The status values here could be decoded by reading the documentation for the "wait" system procedure, and looking up the correct part of the value in the sys_errlist[] array. That is left as an exersize for the reader. ------------------------------------------------------------------------ To compile, some systems may need #include <sys/types.h>. Also, note the conditionalized code in bad_malloc. If your system only gets the signal "segmentation violation" then you may need to consider conditionalizations along this line. However, on a machine with a segmented address space, that has "instructions" in one segment and "data" in another, it is highly unlikely that the code for setting up and invoking the "void (*badboy)()" will have any interesting effect. Nothing other than an easily handled SIGSEGV will result in the inner testing loop. Some INTEL 80386 and DEC PDP-11 systems would be examples of this situation. -- Dave Horsfall (VK2KFU) | dave@esi.com.au | VK2KFU @ VK2AAB.NSW.AUS.OC | PGP 2.6 Opinions expressed are mine. | E7 FE 97 88 E5 02 3C AE 9C 8C 54 5B 9A D4 A0 CD